Roundup Semanal Ruby, Rails & IA: Rails 7.2 Chega ao Fim da Vida, o Benchmark Agents on Rails e o HTTP QUERY (9–15 de agosto de 2026)

A semana de 9 a 15 de agosto não trouxe nenhum patch de segurança de Ruby ou Rails, o que deixa o prazo que de fato venceu como o item mais urgente da lista: o Rails 7.2 saiu do suporte de segurança no dia 9. Junto com isso, a Rails Foundation publicou os primeiros números concretos sobre o desempenho de coding agents em código Rails real, o suporte a HTTP QUERY entrou em revisão, e uma discussão antiga sobre governança virou um fork de verdade.

Rails 7.2 saiu do suporte de segurança em 9 de agosto

A política de manutenção do Rails dá a cada série minor dois anos de correções de segurança a partir do primeiro release da série. Para a 7.2.x, esse prazo venceu em 9 de agosto de 2026. Não há período de carência: o próximo CVE divulgado contra Action Pack ou Active Record será corrigido nas linhas 8.0 e 8.1, e a 7.2 simplesmente vai carregar a falha.

O destino importa tanto quanto a decisão de sair. O Rails 8.0.x deixou de receber correções de bugs em 7 de maio de 2026, e seu suporte de segurança termina em 7 de novembro de 2026 — menos de três meses à frente. Parar na 8.0 compra um trimestre e um segundo projeto de upgrade. O Rails 8.1.x tem correções de bugs até 10 de outubro de 2026 e segurança até 10 de outubro de 2027, o que faz dele o único alvo que dá fôlego.

Se o salto de duas minors for um projeto de vários sprints, passe pela 8.0 sem problema — mas coloque a etapa da 8.1 no mesmo plano, porque a 8.0 está a três meses do próprio fim de vida.

Agents on Rails: a Foundation colocou números em código Rails escrito por agentes

Em 12 de agosto a Rails Foundation anunciou o Agents on Rails, um benchmark que mede como coding agents se saem em aplicações Rails reais, encomendado à Evil Martians. O primeiro relatório saiu no dia seguinte.

O Stage 1 cobre tarefas atômicas — problemas pequenos e autocontidos que isolam uma capacidade específica. São 21 delas rodando contra o Writebook v1.2.1, três execuções cada: 63 runs por modelo, 504 no total entre oito modelos frontier e open-weight, avaliados em acurácia, tempo mediano, média de tokens, custo médio e recall de APIs do Rails.

Em acurácia, o Claude Opus 5 liderou com 92% (58 de 63 runs). O Fable 5 ficou em torno de 95%, mas se recusou a executar tarefas ligadas a segurança. O GPT-5.6 Sol marcou 84% e o Luna, 73% nas configurações padrão de reasoning. É no custo que a tabela incomoda: o Luna completou os 63 runs por US$ 0,91, enquanto o Opus custou cerca de 132 vezes mais por 19 pontos percentuais de acurácia. O tempo mediano por tarefa foi de 3,3 minutos no Luna, 5 minutos no Sol e 16 minutos no Muse, que passou 82% desse tempo pensando.

O achado que vale levar para as suas decisões de tooling é que o que separou os modelos foi conhecimento de framework, não capacidade bruta. O recall de APIs do Rails variou de 8% no DeepSeek V4 Flash a 35% no Fable 5, e as execuções que buscaram a API correta do Rails tiveram 92% de sucesso, contra 87% das soluções feitas na mão. Um modelo que não sabe que normalizes existe vai te escrever um callback before_validation que quase funciona.

O corpus está público em rails/ai-evals sob licença MIT, com um canary GUID embutido em cada instrução de tarefa para manter o benchmark fora de datasets de treino. O harness em Ruby, o lemans, está a caminho de ser open-sourced. O leaderboard está no ar e já traz mais modelos do que o relatório original. O Stage 2 avança para trabalho multi-etapa: adicionar features e construir apps do zero.

HTTP QUERY entra em revisão, e o Active Record ganha um lote de mudanças

O This Week in Rails de 14 de agosto abriu com o pull request que adiciona suporte a HTTP QUERY — ainda aberto no momento em que escrevo, então trate como direção, não como API. Ele traz um helper de rota query, match via: :query, request.query?, request.request_method_symbol, um helper query nos integration tests, e isenta QUERY da forgery protection do mesmo jeito que GET e HEAD. O caso de uso é aquele endpoint de busca cujo payload de filtros passou do que cabe na URL e virou POST — seguro e idempotente na prática, mas inseguro e não cacheável para todo proxy no caminho. O QUERY dá a esse request um verbo honesto.

Outros merges que vale conhecer antes que apareçam no seu próximo upgrade:

• find_by_sql e count_by_sql agora usam bind parameters para argumentos em forma de array, passando por Arel::Nodes::BoundSqlLiteral em vez de interpolar via sanitize_sql — consistente com o where, melhor para statement caching e com menos superfície de injection na saída de emergência do SQL cru. Na mesma área, o alias create do adapter foi deprecado em favor de insert.
• O default de sql_mode do MySQL mudou: em vez de acrescentar STRICT_ALL_TABLES, o Rails passa a acrescentar TRADITIONAL. Isso pesa principalmente em RDS e Aurora MySQL, onde o default vazio do servidor deixava NO_ZERO_IN_DATE, NO_ZERO_DATE e ERROR_FOR_DIVISION_BY_ZERO silenciosamente de fora. Para manter o comportamento antigo, defina variables: { sql_mode: "STRICT_ALL_TABLES" } explicitamente no database.yml.
• Os schema readers aceitam múltiplas tabelas — indexes, primary_keys, foreign_keys, check_constraints, exclusion_constraints e unique_constraints recebem uma lista e devolvem um hash. Menos round trips em código de introspecção de schema.
• normalizes agora roda antes da validação de tipo, então um valor como " Pending " deixa de ser rejeitado antes que a normalização do enum tenha chance de agir.
• Os comandos do CommandRecorder de migration agora são tuplas de 4 elementos — [cmd, args, kwargs, block] em vez de três com os kwargs empacotados em args. Se você tem helpers de migration reversível customizados, eles vão precisar de ajuste.

Mosscap: um fork LTS comunitário do Rails 8

Em 9 de agosto, Lucas Dohmen publicou Rails is done, anunciando um fork inicialmente batizado de Amiko e agora chamado Mosscap. A proposta é um Rails 8.x LTS mantido pela comunidade: melhorias pontuais sem quebrar compatibilidade, atenção especial ao asset pipeline e estabilidade acima de inovação. A premissa técnica dele é que o núcleo do Rails — com exceção do Zeitwerk — não mudou de forma relevante desde a 6.0, e que boa parte das adições recentes são componentes opcionais, não evolução do framework. A motivação declarada é governança, não código.

Independentemente do que você achar do enquadramento, a pergunta operacional é estreita: um fork consegue de fato absorver e entregar patches de segurança na linha Rails 8? É a única coisa que o tornaria um alvo viável para uma aplicação que não acompanha a esteira de upgrades, e um anúncio de lançamento não demonstra isso. A contra-argumentação de Ryan Bigg — de que o Hanami já existe — merece peso.

O GPT-5.6 faz o mesmo argumento do benchmark do Rails

O builder's guide do GPT-5.6 da OpenAI, publicado em 13 de agosto, vale ser lido ao lado do relatório do Rails porque chega à mesma conclusão pelo lado do fornecedor. A família se divide em Sol (o flagship, com ajustes de reasoning), Luna (otimizado para custo em volume) e Terra. As adições à Responses API são a parte substantiva para quem está plugando agentes em uma app Rails: persistência de reasoning entre turnos, compactação nativa de conversas longas, orquestração multi-agente, programmatic tool calling — em que o modelo escreve JavaScript para orquestrar tools fora da janela de contexto — e prompt caching com TTL mínimo de 30 minutos e cache breakpoints determinísticos.

Os números que a OpenAI destaca fazem o argumento de custo de forma direta: o Luna atinge 98% da acurácia de extração do GPT-5.5 por um dezoito avos do custo, e empata com ele no BrowseComp (84,04% contra 84,36%) por US$ 1,33 em vez de US$ 33,27. O enquadramento deles é que trabalho que "antes exigia um modelo frontier em cada passo" agora pode ser roteado para modelos menores com reasoning effort ajustado. Duas medições independentes apontando na mesma direção são um sinal mais forte do que qualquer uma isolada.

A saída do Claude ganha watermark de texto

A Anthropic explicou como funciona o watermark de texto do Claude em 14 de agosto, com envio previsto para modelos futuros sob os compromissos do EU AI Act. O mecanismo enviesa a aleatoriedade usada quando o modelo escolhe entre palavras equivalentes, com uma chave que torna o padrão verificável para quem a tem e invisível para quem não tem; imagens recebem credenciais C2PA no lugar. A ressalva importa mais que o mecanismo se você pensou em usar isso num pipeline de review: o watermark é escasso ou ausente em texto muito restrito, e código é citado explicitamente como um caso com pouco espaço para codificar qualquer coisa. Uma API de detecção foi prometida, mas não lançada. Ela não vai te dizer se um pull request foi escrito por um agente.

Escolha editorial: "Ruby and Rails Performance Roundup: The Backlog Edition"

O roundup de performance de Maciej Mensfeld, publicado em 12 de agosto, percorre 40 PRs de performance em Ruby e Rails com números de benchmark anexados. O destaque é uma correção no JSON::ResumableParser, que vinha re-decodificando números incompletos a cada chunk: um número de 128.000 dígitos alimentado em chunks de 128 bytes caiu de 3,07s para 8,13ms. Também estão lá o garbage collection por Ractor, que reduz o custo de escalar de 1 para 16 Ractors de 10,17x o wall time de um único Ractor para 3,32x, e uma correção de mutação em params hash que derruba um hash de 200 entradas e 3 níveis de 5.825 para 1.612 alocações. Vinte minutos bem gastos se você quer saber onde o runtime está de fato ficando mais rápido.

Ações da semana

• Se alguma aplicação em produção está na Rails 7.2, agende o upgrade agora — ela não recebe correções de segurança desde 9 de agosto, e mire na 8.1, não na 8.0.
• Confira também as apps na Rails 8.0. O suporte de segurança termina em 7 de novembro de 2026; coloque o upgrade para a 8.1 em um sprint antes do planejamento do Q4 fechar.
• Faça um grep por helpers de migration reversível customizados que desempacotam comandos do CommandRecorder como arrays de 3 elementos, e por chamadas de adapter a create em vez de insert.
• Se você roda MySQL, confirme que nada depende do default atual STRICT_ALL_TABLES antes que TRADITIONAL vire a linha de base.
• Baixe o corpus do rails/ai-evals e rode o modelo que você usa contra ele. Seu codebase não é o Writebook, mas a métrica de recall de API se transfere.
• Reprecifique seu pipeline de agentes contra as colunas de custo do benchmark do Rails e do guia do GPT-5.6. Rotear tarefas atômicas para um modelo mais barato virou uma economia mensurável, não um palpite.